fix(dashboard): keep the reply name and map preview inside the panel - #1429
Merged
Conversation
Two elements in the chat pane carried no width constraint of their own, so once the room was narrow they painted through their neighbours and out past the panel's clip. The reply banner's quoted name was the only text node there without the truncation its own sibling body already has, so an unbreakable name kept its box and its ink ran across the close button: 44px across it at 25 characters and 162px at 40, measured at the narrowest two-pane width. The location message's map preview carried its size as an inline pixel width, the one media element in a bubble not bounded by its container. It stayed 220px wide however narrow the room got, passing the clip by 15px. It now sizes from a class beside the other media types and keeps the same cap, bounded by the bubble.
rmyndharis
force-pushed
the
fix/chats-narrow-overflow-residuals
branch
from
August 21, 2026 08:18
99268b2 to
9c11dd1
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two elements in the chat pane carry no width constraint of their own, so once the room is narrow they paint through their neighbours and out past
.chats-layout's clip. Neither is caused by the composer work in #1425 or #1427; both are pre-existing.What changed
.chats-page .replying-to-titlegainswhite-space: nowrap,overflow: hiddenandtext-overflow: ellipsis. It was the only text node in the reply banner without them; its own sibling.replying-to-bodyhas had all three all along.style={{ maxWidth: 220, ... }}to a.chats-page .chat-location-mediaclass withmax-width: min(220px, 100%). It keeps the same 220px cap but is now bounded by the bubble, which is how every other media element in a bubble is already sized.min()follows the existing use inCustomSelect.css.Impact
Measured in headless Chromium with the real webfont and the production globals, navigation expanded. 889px is the narrowest viewport at which the two-pane layout survives once #1427 lands, and 243px is the room there.
Reply banner, quoted name with no break opportunity, measured from the text's own rectangle because the element box reports no overflow at all:
After, the title is clipped inside its box and shows an ellipsis. The discriminating evidence is structural plus visual, not the rectangle:
scrollWidth385 againstclientWidth133 with a non-visible overflow, and the two screenshots hash differently. ARangerectangle is the wrong instrument here, since it is not clipped by an ancestor's overflow and reports where the text would sit rather than where it paints.Map preview:
The cap still binds wherever there is room for it, so nothing changes on an ordinary desktop width.
Verification
main.lint,format:check,typecheck,i18n:check,build,test:unit. Docs lanetest:docs, 264 tests. The page-CSS scope gate passes, 11 of 11.format:checkis clean.Note
The changelog entry sits at the same anchor as the one in #1427. Whichever lands second needs a one line rebase there, and a conflicted PR in this repository gets no CI run at all while reporting "no checks reported", so re-check it after rebasing.
Fixes #1428